home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13596 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: druid.borland.com!usenet
  2. From: pete@borland.com (Pete Becker)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: 26 Mar 1996 16:23:59 GMT
  6. Organization: Borland International
  7. Message-ID: <4j95mv$74n@druid.borland.com>
  8. References: <4j2kgg$svj@sam.inforamp.net> <4j3vc6$nrk@news1.h1.usa.pipeline.com>
  9. NNTP-Posting-Host: pbecker.borland.com
  10. Mime-Version: 1.0
  11. Content-Type: Text/Plain; charset=ISO-8859-1
  12. X-Newsreader: WinVN 0.99.5
  13.  
  14. In article <4j3vc6$nrk@news1.h1.usa.pipeline.com>, grantp@usa.pipeline.co 
  15. says...
  16. >
  17. >On Mar 24, 1996 04:53:18 in article <Re: Coding Standards>,
  18. >'rmorin@inforamp.net (Randy Charles Morin)' wrote: 
  19. > 
  20. > 
  21. >>In article <4iuu6k$6a6@druid.borland.com>, 
  22. >>pete@borland.com (Pete Becker) wrote: 
  23. >>>Unfortunately, if you don't follow guidelines like this, you will miss
  24. >your  
  25. >>>subsequent maintenance deadlines by many years. You'll spend all your
  26. >time  
  27. >>>tracking down mysterious failures that arise when you try to enhance the 
  28. >
  29. >>>program, rather than spending time on the enhancements themselves. 
  30. >> 
  31. >>But if you follow these guidelines, your initial release will miss your  
  32. >>subsequent maintenance deadlines.  You have to be reasonable in these  
  33. >>situations.   
  34. > 
  35. >Right.  I will nearly always vote on the side of reasonableness. Seems  
  36. >to me that since writing a trivial copy constructor can be implemented 
  37. >in a matter of seconds, it's just a good habit to write one even if its 
  38. >need isn't obvious at the time the class is in its initial stages of 
  39. >development.  I doubt seriously if a few seconds, or even a minute or 
  40. >two, spent at writing a copy constructor for all classes will cause 
  41. >significant delays in product delivery. 
  42. > 
  43.  
  44. Actually, it was not my intention to endorse automatically writing trivial copy 
  45. constructors. I do trust maintenance programmers to recognize that code they've 
  46. added requires a copy constructor, and to either change the existing one or 
  47. write a new one as necessary. What I had in mind was rules like always having a 
  48. virtual destructor whenever you have any other virtual functions. Violate this 
  49. one at your peril: you may not intend to pass pointers to this function 
  50. initially, but two days before you're due to ship your product you'll find a 
  51. bug that requires deleting a pointer to your class, and it will not work right 
  52. if you don't have a virtual destructor.
  53.  
  54. >>        Why not make the standard that if you add a data member that may  
  55. >>cause the default copy constructor to produce erroneous results, then 
  56. >>make one explicitly?  This way you only have to write them when you need 
  57. >>to and you have the same end result. 
  58. >> 
  59. >If we can rely on the maintenance programmer to think about the 
  60. >problem, then OK, but that's not the real world.  IMHO, Pete Becker is 
  61. >absolutely correct in this matter -- well, maybe he exaggerated just 
  62. >a little bit... 
  63.  
  64. You caught me: I do sometimes exaggerate just a little bit...
  65.  
  66.